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[57] ABSTRACT 

A computer network having multiple, dissimilar network 
devices includes a system for implementing high-level, 
network policies. The high-level policies, which are gener- 
ally device-independent, are translated by one or more 
policy servers into a set of rules that can be put into effect 
by specific network devices. Preferably, a network admin- 
istrator selects an overall traffic template for a given domain 
and may assign various applications and/or users to the 
corresponding traffic types of the template. Location- 
specific policies may also be established by the network 
administrator. The policy server translates the high-level 
policies inherent in the selected traffic template and location- 
specific policies into a set of rules, which may include one 
or more access control lists, and may combine several 
related rules into a single transaction. Intermediate network 
devices, which may have one or more roles assigned to their 
interfaces, are configured to request traffic management 
information from the policy server which replies with a 
particular set of transactions and rules. The rules, which may 
correspond to the particular-roles.assigned to the interfaces, 
are then utilized by the intermediate devices to configure 
their particular services and traffic management mecha- 
nisms. Other rules are utilized by the intermediate devices to 
classify packets with a particular priority and/or service 
"value and to treat classified packets in a particular manner so 
as to realize the selected high-level policies within the 
domain. 

18 Claims, 9 Drawing Sheets 
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METHOD AND APPARATUS FOR DEFINING 
AND IMPLEMENTING HIGH-LEVEL 
QUALITY OF SERVICE POLICIES IN 
COMPUTER NETWORKS 

FIELD OF THE INVENTION 

The present invention relates generally to computer 
networks, and more specifically, to a method and apparatus 
for applying high-level, quality of service policies at dis- 
similar computer network devices. 

BACKGROUND OF THE INVENTION 

A computer network typically comprises a plurality of 
interconnected entities that transmit (i.e., "source") or 
receive (i.e., "sink") data frames. A common type of com- 
puter network is a local area network ("LAN") which 
typically refers to a privately owned network within a single 
building or campus. LANs employ a data communication 
protocol (LAN standard), such as Ethernet, FDDI or token 
ring, that defines the functions performed by the data link 
and physical layers of a communications architecture (i.e., a 
protocol stack), such as the Open Systems Interconnection 
(OSI) Reference Model. In many instances, multiple LANs 
may be interconnected by point-to-point links, microwave 
transceivers, satellite hook-ups, etc. to form a wide area 
network ("WAN"), metropolitan area network ("MAN") or 
intranet. These LANs and/or WANs, moreover, may be 
coupled through one or more gateways to the Internet. 

One or more intermediate devices are often used to couple 
LANs together and allow the corresponding entities to 
exchange information. For example, a bridge may be used to 
provide a "bridging" function between two or more LANs. 
Alternatively, a switch may be utilized to provide a "switch- 
ing" function for transferring information, such as data 
frames, among entities of a computer network. Typically, the 
switch is a computer having a plurality of ports that couple 
the switch to several LANs and to other switches. The 
switching function includes receiving data frames at a 
source port and transferring them to at least one destination 
port for receipt by another entity. 

Switches may operate at various levels of the communi- 
cation protocol stack. For example, a switch may operate at 
layer 2 which, in the OSI Reference Model, is called the data 
link layer and includes the Logical Link Control (LLC) and 
Media Access Control (MAC) sub-layers. Data frames at the 
data link layer typically include a header containing the 
MAC address of the entity sourcing the message, referred to 
as the source address, and the MAC address of the entity to 
whom the message is being sent, referred to as the destina- 
tion address. To perform the switching function, layer 2 
switches examine the MAC destination address of each data 
frame received on a source porL The frame is then switched 
onto the destination port(s) associated with that MAC des- 
tination address. 

Other devices, commonly referred to as routers, may 
operate at higher communication layers, such as layer 3 of 
the OSI Reference Model, which in TCP/IP networks cor- 
responds to the Internet Protocol (IP) layer. Data frames at 
the IP layer also include a header which contains an IP 
source address and an IP destination address. Routers or 
layer 3 switches may re-assemble or convert received data 
frames from one LAN standard (e.g., Ethernet) to another 
(e.g. token ring). Thus, layer 3 devices are often used to 
interconnect dissimilar subnetworks. 

User Priority 

FIG. 1 is a block diagram of a data link (e.g., Ethernet) 
frame 100 which includes a MAC header 102 and a data 
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field 104. MAC header 102 includes a MAC destination 
address (MAC DA) field 106 and a MAC source address 
(MAC SA) field 108. Recently, a proposal was made to 
insert a new field after the MAC SA field 108. More 

5 specifically, the Institute of Electrical and Electronics Engi- 
neers (IEEE) is working on a standard, the IEEE 802.1 Q 
draft standard, for adding information to MAC headers. In 
particular, the 802.1 Q standard defines a tag header 110 
which is inserted immediately following the MAC DA and 

to MAC SA fields 106, 108. 

The tag header 110 comprises a plurality of sub-fields, 
including a Tag Protocol Identifier (TPID) field 112, a 
user_j)riority field 114, a Canonical Format Indicator (CF1) 
field 116 and a Virtual Local Area Network Identifier 

15 (VLAN ID) field 120. The user__priority field 114 permits 
network devices to select a desired priority of data link 
frames. In particular, in an IEEE appendix, referred to as the 
802. lp standard, the IEEE has defined eight possible values 
of user priority (0-7), each of which is associated with a 

20 specific traffic type. The proposed user priority values and 
corresponding traffic types specified in the 802.1 p standard 
are as follows. 
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User Priority 

Value Traffic Type Description 
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Background 


bulk transfers 


2 


Sparc/Reserved 


n/fl 


0 


Best Effort 


current LAN traffic 


3 


Excellent Effort 


best effort type of services 
(eg., for an organization's 
most important customers) 


4 


Controlled Load 


important business 
applications 


5 


Video (<100 milliseconds 


minimum jitter 




latency aad jitter) 


6 


Voice (<10 milliseconds 


one-way transmission through 




latency arid jitter) 


the LAN 


7 


Network Control 


characterized by a "must get 
there" requirement to maintain 
and support the network 
infrastructure 



_j- An in tcrmcdiate device - may provide aphirality of transit 
m ission priority, queues.per . pjjrtjindi^rsuanUoJhc 80271 p 

45 stMdard,lmay"assigii"framcs-to different queues of Vdesti; 
naUon port. on. the basis of die faupe's user priority value' 
For example, frames with a user priority of "0" are^laced 
in the "0" level priority queue (e.g., non-expedited traffic), 
whereas frames with a user priority of "3" are placed in the 

50 level "3" priority queue. Furthermore, frames stored in a 
higher level queue (e.g., level 3/exceIlent effort) are prefer- 
ably forwarded before frames stored in a lower level queue 
(e.g., level 1/background). This is commonly referred to as 
Priority Queuing. Thus, by setting the contents of the 

55 user_priority field 114 to a particular value, a device may 
affect the speed with which the corresponding frames 
traverse the network. 

If a particular intermediate device has less than eight 
priority queues per port, several of the IEEE traffic types 

60 may be combined. For example, if only three queues are 
present, then queue 1 may accommodate best effort, excel- 
lent effort and background traffic types, queue 2 may accom- 
modate controlled load and video traffic types and queue 3 
may accommodate voice and network control traffic types. 

65 The IEEE 802. lp standard also recognizes that intermediate 
devices may regenerate the user priority value of a received 
frame. That is, an intermediate device may forward the 
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frame with a different user priority value (still within the 
range of 0-7) than the one it had when the frame was 
received. Nevertheless, the standard recommends leaving 
the user priority value un -changed. 
Type of Service 

FIG. 2 is a block diagram of a portion of an Internet 
Protocol Version 4 (IPv4) compliant IP header 200. The IP 
header 200 is also made up of a plurality of fields, including 
a type_of_service (ToS) field 202, a time to live (TTL) field 
204, an IP source address (IP SA) field 206 and an IP 
destination address (IP DA) field 208. The ToS field 202 is 
intended to allow an entity to specify the particular service 
it wants, such as high reliability, fast delivery, accurate 
delivery, etc., and comprises a number of sub-fields. The 
sub-fields include a three bit IP precedence (IPP) field 210, 
three one bit flags (D, T and R) 212, 214 and 216 and two 
unused bits 218. By setting the various flags, a host may 
indicate which overall service it cares most about (i.e., 
Delay, Throughput and Reliability). Although the ToS field 
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predefined criteria. When a packet is received by such a 
device, it is tested against each of the criteria statements of 
the corresponding list. If a match is found, the packet is 
either forwarded or dropped as provided by the list. The 
criteria may be source address, destination address, or 
upper-layer application based on their TCP/UDP port num- 
bers. For example, an access list may allow e-mail to be 
forwarded but cause all Telnet traffic to be dropped. Access 
lists may be established for both inbound and outbound 
traffic and arc most commonly configured at layer 3 devices 
located at the border of a network (i.e., gateways or 
firewalls) to provide security to the network. 
Congestion Control 

Congestion typically refers to the presence of too many 
packets in a subnet or a portion of a network, thereby 
degrading the network's performance. Congestion occurs 
when the network devices are unable to keep up with an 
increase in traffic. As described above, a layer 3 device 
typically has one or more priority queues associated with 



202 was intended to allow layer 3 devices to choose between 20 each interface. As packets are received, they are added to the 



different links (e.g., a satellite link with high throughput or 
a leased line with low delay) depending on the service being 
requested, in practice, most layer 3 devices ignore the 
contents of the ToS field 202 altogether. Instead, protocols at 
the transport layer (layer 4) and higher typically negotiate 
and implement an acceptable level of service. Version 6 of 
the Internet Protocol (IPv6) similarly defines a traffic class 
field, which is also intended to be used for defining the type 
of service to be applied to the corresponding packet. 

Recently, a working group of the Internet Engineering 
Task Force (IETF), which is an independent standards 
organization, has proposed replacing the ToS field 202 with 
a one octet differentiated services (DS) field 220. The first 
six bits of the DS field specify a differentiated services 
codepoint while the last two bits are unused. Layer 3 devices 
that are DS compliant apply a particular per-hop forwarding 
behavior to packets based on the contents of their DS fields 
220. Examples of per-hop forwarding behaviors include 
expedited forwarding and assured forwarding. The DS field 
220 is typically loaded by DS compliant intermediate 
devices located at the border of a DS domain, which is a set 
of DS compliant intermediate devices under common net- 
work administration. Thereafter, interior DS compliant 
devices along the path simply apply the assigned forwarding 
behavior to the packet. 

Although layer 3 devices, like their layer 2 counterparts, 
typically have multiple priority queues per port or interface, 
layer 3 devices often apply scheduling patterns that are more 
sophisticated than simple Priority Queuing. For example, 
some layer 3 devices forward one packet from each queue in 
a round robin fashion. Another approach, referred to as fair 
queuing, simulates a byte-by-byte round robin to avoid 
allocating more bandwidth to sources who transmit large 
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appropriate priority queue for forwarding. Nevertheless, if 
packets are added to the queue faster than they can be 
forwarded, the queue will eventually be filled forcing the 
device to drop any additional packets for that queue. The 
dropping of packets when a queue is full is referred to as tail 
drop. The point at which tail drop occurs, moreover, may be 
configured to something less than the capacity of the queue. 

Since tail dropping discards every packet over the queue 
limit, it often affects multiple upper layer applications simul- 
taneously. Furthermore, many upper layer applications, such 
as TCP, re-send messages if no acknowledgments are 
received. Thus, the presence of tail dropping can cause 
global synchronization among upper layer applications, sig- 
nificantly exacerbating the congestion problem. To avoid 
global synchronization, some layer 3 devices use Random 
Early Detection (RED), which selectively drops packets 
when congestion first begins to appear. By dropping some 
packets early before the priority queue is full, RED avoids 
dropping large numbers of packets all at once. In particular, 
when a calculated average queue depth exceeds a minimum 
threshold, the device begins dropping packets. The rate at 
which packets are dropped increases linearly as a function of 
a probability constant. When a maximum threshold is 
reached, all additional packets are dropped. An extension to 
RED is Weighted Random Early Detection (WRED), which 
applies different thresholds and probability constants to 
packets associated with different traffic flows. Thus, WRED 
allows standard traffic to be dropped more frequently than 
premium traffic during periods of congestion. 

Service Level Agreements 

To interconnect dispersed computer networks, many orga- 
nizations rely on the infrastructure and facilities of service 
providers. For example, an organization may lease a number 



packets than to those who only send small packets. Another ss Q f Tl lines to interconnect various LANs. These organiza- 
' 1 *" " " " ' tions typically enter into service level agreements with the 

service providers, which include one or more traffic speci- 
fiers. These traffic specifiers may place limits on the amount 
of resources that the subscribing organization will consume 
for a given charge. For example, a user may agree not to 
send traffic that exceeds a certain bandwidth (e.g., 1 Mb/s). 
Traffic entering the service provider's network is monitored 
(i.e., "policed 1 *) to ensure that it complies with the relevant 
traffic specifiers and is thus "in-profile". Traffic that exceeds 
a traffic specifier (i.e., traffic that is "out-of-profile") may be 
dealt with in a number of ways. For example, the exceeding 
traffic may be dropped or shaped. With shaping, the out-of- 



approach, called Weighted Fair Queuing (WFQ), allocates 
more bandwidth to specific traffic flows or sources, such as 
file servers, based on source IP address, Transmission Con- 
trol Protocol (TCP) or User Datagram Protocol (UDP) 
source port, etc. 

Some networking software, including the Internetwork 
Operating System (IOS) from Cisco Systems, Inc., support 
the creation access control lists or filters , which are typically 
used to prevent certain traffic from entering or exiting a 
network. In particular, certain layer 3 devices utilize access 
lists to control whether routed packets should be forwarded 
or filtered (i.e., dropped) by the device based on certain 
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profile traffic is temporarily stored until the demand drops 
below the threshold. Another option is to mark the traffic as 
exceeding the traffic specifier, but nonetheless allow it to 
proceed through the network. If there is congestion, an 
intermediate device may drop this "marked" or down graded 
traffic first in an effort to relieve the congestion. Another 
option is to change the accounting actions for this out-of- 
profile traffic (i.e., charge the user a higher rale). 

Allocation of Network Resources 

As shown, computer networks include numerous services 
and resources for use in moving traffic around the network. 
For example, different network links, such as Fast Ethernet, 
Asynchronous Transfer Mode (ATM) channels, network 
tunnels, satellite links, etc., offer unique speed and band- 
width capabilities. Particular intermediate devices also 
include specific resources or services, such as number of 
priority queues, filter settings, availability of different queue 
selection strategies, congestion control algorithms, etc. 
Nonetheless, these types of resources or services are highly 
device-specific. That is, most computer networks include 
intermediate devices manufactured by many different 
vendors, employing different hardware platforms and soft- 
ware solutions. Even intermediate devices from the same 
vendor may be running different software versions and thus 
provide different functionality. Thus, there is no consistency 
of resources at each of the intermediate devices and, 
therefore, it is generally not possible to simply select a single 
set of parameters for use in configuring all of them. 

In addition, the allocation of network resources and 
services is becoming an important issue to network admin- 
istrators and service providers as greater demands are being 
placed on their networks. Nonetheless, at the present time, 
there are few if any techniques available for applying traffic 
management policies across a network. Instead, the alloca- 
tion of network resources and services is typically achieved 
by manually configuring the interfaces of each intermediate 
device. For example, to the extent there arc parameters 
associated with a particular queuing strategy available at a 
given intermediate device (e.g., queue length for tail drop 
and minimum, maximum and mark probability for RED), 
these parameters must be set dev ice-by -de vice by the net- 
work administrator. This is a time consuming and error 
prone solution. In addition, there arc few if any tools 
currently available to network administrators suggesting 
how various network resources and services might be coher- 
ently allocated in order to implement any general policies. 
Accordingly, the ability to allocate network services and 
resources to implement network-wide quality of service 
policies is difficult and time-consuming. 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a method 
and apparatus for applying high-level quality of service 
policies. 

It is a further object of the present invention to provide a 
method and apparatus for translating high-level policies into 
a form that may be understood and applied by numerous 
dissimilar network devices. 

It is a further object of the present invention to classify 
data traffic upon its entering a given network domain and to 
manage that traffic based on its classification. 

Briefly, the invention relates to a method and apparatus 
far implementing high-level policies within a computer 
network having multiple, dissimilar network devices. The 
high-level policies, which arc generally device -independent, 
are selected by a network administrator and translated by 
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one or more policy servers into a set of rules that can be 
applied by specific network devices. In particular, a network 
administrator first selects an overall traffic template for a 
given network domain and may assign various applications 

5 and/or users to the corresponding traffic types of the tem- 
plate. The network administrator may also select or define 
one or more location-specific policies. As information is 
added to the template and the location-specific policies are 
defined, one or more corresponding data structures may be 

jo up-dated. The selected traffic template, location-specific 
policies and data structures are received at one or more 
policy servers within the network domain. Each policy 
server translates the high-level policies inherent in the 
selected traffic template, location-specific policies and data 

15 structures into a set of rules and may combine several related 
rules into a single transaction. Upon initialization, interme- 
diate devices request traffic management information from 
the one or more policy servers. The policy server replies 
with a particular set of transactions and rules that are utilized 

20 by the intermediate devices for traffic management deci- 
sions. By propagating these rules across the network 
domain, each of the dissimilar intermediate devices can 
configure its corresponding traffic management components 
and mechanisms to operate in such a manner as to imple- 

25 ment the high-level policies selected by the network admin- 
istrator. 

More specifically, a particular differentiated service (DS) 
codepoint is preferably assigned to each traffic type of the 
selected traffic template, based on the overall priority estab- 

30 lished by the network administrator. The DS codepoint 
essentially sets the overall treatment of the corresponding 
traffic type within the network domain. Aset of classification 
rules are then generated by the policy server instructing 
intermediate devices to associate particular traffic types with 

35 their corresponding DS codepoints. For example, the clas- 
sification rules may direct intermediate devices to load a 
particular DS codepoint within the DS field of received 
Internet Protocol (IP) messages, depending on the type of IP 
message (e.g., all traffic associated with a stock exchange 

40 application). Devices that are not DS-compliant may receive 
classification rules instructing them to load a given value 

within type of_service or user, priority fields of received 

packets or frames. The classification rules, which may 
include one or more access control lists, are preferably 

45 provided to all intermediate devices located at the boundary 
of the network domain so that traffic can be associated with 
its corresponding DS codepoint as soon as it enters the 
domain. Classification rules may also be used to associate 
Quality of Service (QoS) labels to specific traffic types. QoS 

50 labels are also used by intermediate devices in making traffic 
management decisions, although, unlike the DS codepoints 
which are generally present in messages traveling the 
network, QoS labels are only associated with messages 
while they remain within the intermediate device. Classifi- 

55 cation rules may also be used to assign DS codepoints and/or 
QoS labels to data traffic generated within the network 
domain from un-trusted sources. 

Tb implement specific traffic management policies or 
treatments, the policy server also defines a plurality of 

60 behavioral rules that basically instruct the intermediate 
devices how to manage data traffic that has been associated 
with a particular DS codepoint, QoS label, type of service 
and/or user priority value. For example, a behavioral rule 
may instruct the intermediate devices to place all messages 

65 associated with a particular DS codepoint (e.g., data frames 
from a stock exchange application or from a corporate 
executive) in a high priority queue. To implement traffic 



10/06/2003, EAST Version: 1.04.0000 



6,167,445 



8 



management policies that are independent of DS codepoints 
and/or QoS labels, the policy servers preferably generate one 
or more configuration rules. Configuration rules generally 
instruct intermediate devices how to set-up their various 
traffic management components or mechanisms. For 
example, a configuration rule may contain a list of conges- 
tion algorithms in descending order of preference. Upon 
receipt of the configuration rule, an intermediate device 
examines the list and preferably adopts the first congestion 
algorithm that it supports. 

In the preferred embodiment, the policy servers and 
intermediate devices utilize an extension to the Common 
Open Policy Service (COPS) protocol to exchange mes- 
sages. More specifically, an intermediate device sends a 
Query Configuration message to the policy server that 
contains specific information about itself, such as the num- 
ber and type of interfaces, whether the device is at a 
boundary of the intermediate domain and/or whether its 
interfaces are coupled to trusted or un-trusted devices. This 



10 



15 



switch 308 and routers 316-318, by links 324a-324c. The 
network 300 also includes one or more repositories, such as 
repository 326, that is preferably connected to each policy 
server 322 by a link 328. The repository 326 may be an 
organization-based directory server. 

The network 300 may further include one or more 
Dynamic Host Configuration Protocol (DHCP) servers, such 
as server 329, that is also coupled to the policy server 322 
either directly or indirectly. DHCP, which is defined at 
Request for Comments (RFC) 2131, is built upon a client- 
server model, where DHCP servers allocate IP addresses and 
deliver network configuration parameters to DHCP clients 
(e.g., hosts or end stations). Because IP addresses can be a 
scarce resource in some computer networks, DHCP servers 
assign them only for limited periods of time (referred to as 
a lease). Once a lease has expired, the corresponding IP 
address may be re- assigned to another host. 

Attached to the switches 306-314 and routers 316-318 
are a plurality of end stations 330-346 and servers 348-352, 
which may be file servers, print servers, etc. In particular, 



device-specific information may be loaded in the query 20 four end stations 330-336 are connected to switch 306, one 



message as COPS objects. In response, the policy server 
selects a particular set of transactions or rules responsive to 
the device-specific information and provides them to the 
intermediate device. Preferably, the transactions and rules 



end station 338 and one server 348 are connected to switch 
308, two end stations 340 and 342 are connected to switch 
310, one server 350 is connected to router 318, two end 
stations 344 and 346 are connected to switch 312, and one 



are similarly embedded as COPS objects in response mes- 25 server 352 is connected to switch 314. 



Software entities (not shown) executing on the various 
end stations 330-346 and servers 348-352 typically com- 
municate with each other by exchanging discrete packets or 
frames of data according to predefined protocols, such as the 
30 Transmission Control Protocol/Internet Protocol (TCP/IP), 
the Internet Packet Exchange (IPX) protocol, the AppleTalk 
protocol, the DECNct protocol or NetBIOS Extended User 
Interface (NetBEUI). In this context, a protocol consists of 
a set of rules defining how the entities interact with each 
other. Data transmission over the network 300 consists of 
generating data in a sending process executing on a first end 
station, passing that data down through the layers of a 
protocol stack where the data arc sequentially formatted for 
delivery over (he links as bits. Those frame bits are then 
received at the destination station where they are 
re-assembled and passed up the protocol stack to a receiving 
process. Each layer of the protocol stack typically adds 
information (in the form of a header) to the data generated 
by the upper layer as the data descends the stack. At the 
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sages. As described above, the intermediate device reviews 
these transactions and rules and implements those rules 
which are compatible with its particular traffic management 
components and mechanisms. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and further advantages of the invention may be 
better understood by referring to the following description in 
conjunction with the accompanying drawings, in which: 

FIG. 1, previously discussed, is a block diagram of a prior 
art frame; 

FIG. 2, previously discussed, is a block diagram of a 
portion of a prior art Internet Protocol (IP) header; 

FIG. 3 is a highly schematic, partial diagram of a com- 
puter network; 

FIG. 4 is a highly schematic, partial block diagram of a 
policy server in accordance with the present invention; 

FIG. 5 is a highly schematic, partial block diagram of an 45 donation stt^ 

intermediate device in accordance with the present inven- ^ lhe frame p r0 p aga tes up the layers of the stack until it 

tlon > arrives at the receiving process. 

FIG. 6 is a preferred traffic template that may be selected Preferably, routers 316-318 are layer 3 intermediate 

by a network administrator; and devices and thus operate at the internetwork layer of the 

FIGS. 7A-7F are block diagrams of data structures asso- 50 communication protocol stack implemented within the net- 

ciated with the template of FIG. 6. work 300. For example, routers 316-318 preferably include 

an Internet Protocol (IP) software layer, as defined by the 
well-known TCP/IP Reference Model. Routers 316-318 
implement network services such as route processing, path 

FIG. 3 is a highly schematic block diagram of a computer 55 determination and path switching functions. Switches 

network 300. The network 300 may be segregated into one 306-314 may be layer 2 intermediate devices and thus 

or more network domains by a network administrator, such operate at the data link layer of the corresponding commu- 

as network domains 302 and 304, as described below. The nication protocol stack. Switches 306-314 provide basic 

network 300 includes a plurality of entities, such as end bridging functions including filtering of data traffic by 

stations and servers, interconnected by a plurality of inter- 60 medium access control (MAC) address, "learning"' of a 

mediate devices, such as bridges, switches and routers. In MAC address based upon a source MAC address of a frame 

particular, network 300 includes a plurality of switches and forwarding of the frame based upon a destination MAC 

306-314 and routers 316-318 interconnected by a number address or route information field (RIF). Switches 306-314 

of links 320a to 320/) which may be high-speed point-to- may further provide certain path switching and forwarding 

point or shared finks. Each domain 302 and 304, moreover, 65 decision capabilities normally only associated with routers, 

includes at least one policy server 322 that is preferably In the illustrated embodiment, the switches 306-314 and 

connected to one or more intermediate devices, such as routers 316-318 are computers having transmitting and 



DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 
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receiving circuitry and components, including network 418. As shown, the device-specific filter entity 416 commu- 

interface cards (NICs) establishing physical ports, for nicates with both the policy rule generating engine 414 and 

exchanging data frames. The switches 306-314 and routers the communication engine 418. The communication engine 

316-318 further comprise programmable processing 418, moreover, is preferably configured to exchange mes- 

elements, which may contain software programs pertaining 5 sagcs wit h the intermediate device s ( e.g., switches 306-314 

to the methods described herein. Other computer readable and routers 316-318) of ne twork JUO.ThaT is, communica- 

media may also be used to store the program instructions. In u'on engine 418 is connected to' or includes conventional 

addition, associated with each port or physical network c^iny for transmitting and receiving messages across 

connection is one or more logical connections or interfaces ncrwork unl£Sf ^ch as links 324a-324c. 

defined by the IP software layer. . 

, l . , 10 A server suitable for use as policy server 322 is any 

The terms router or layer 3 intermediate device as used , , xrrrff . _ IT . . *, , 

, , , , ,, . , , Intel/Windows NT® or Unix-based platform, 
herein are intended broadly to cover any intermediate device 

operating primarily at the internetwork layer, including, FIG. S is a partial block diagram of an intermediate 
without limitation, routers as defined by Request for Com- device - » router 318 > m accordance with the preferred 
mcnts (RFC) 1812 from the Internet Engineering Task Force . s embodiment of the present invention. Router 318 preferably 
(IETF), intermediate devices that arc only partially compli- ' mc ** d ™ a communication engine 510 that is coupled to a 
ant with RFC 1812, intermediate devices that provide addi- ** mc management controller 512. The communication 
tional functionality, such as Virtual Local Area Network 510 ^ Q ^ rcd 10 exchange messages with the 
(VLAN) support, IEEE 802.10 support and/or IEEE 802.1D P ollc y 322 / 11)111 ^ communication engme 510, like 
support, etc. The terms switch and layer 2 intermediate „ ^ communication engme 418 at policy server 322 is 
device are also intended to broadly cover any intermediate similarl y connected to or includes conventional circuitry for 
device operating primarily at the data link layer, including, transmitting and receiving messages across the nctwork 300. 
without limitation, devices that are fully or partially com- ™* ^ c management controller 512, which includes a 
pliant with the IEEE 802.1D standard and intermediate P° lic y mlc dccodcr 514 ' 15 C0U P ,cd t0 scvcral components 
devices that provide additional functionality, such as Virtual « and mechanisms. In particular, traffic management control- 
Local Area Network (VLAN) support, IEEE 802.1Q support lcr 512 15 ^P}" 1 10 a packet/frame classifier 516, a traffic 
and/or IEEE 802.1p support, Asynchronous Transfer Mode conditioner entity 518, a queue selector/mapping entity 520 
(ATM) switches, Frame Relay switches, etc. ™ d a scheduler 522. The traffic conditioner 518 also 

It should be understood that the network configuration includcs sub-components, including one or more 

300 of RG. 3 is for illustrative purposes only and that the 30 mctcnn S «tiUes 524, one or more marker entities 526 and 

present invention will operate with other, possibly far more onc or morc shapcr/Unypcr entities 528. The queue selector/ 

complex, network topologies. It should be further under- ma PP m S enuty 520 and scheduler 518 operate on the various 

stood that the repository may be indirectly connected to the ? ucu f cs "tabljshed by router 318 for its ports and/or 

policy servers (e.g., through one or more intermediate interfaces such as queues 530 fl -530e corresponding to an 

devices). 35 interface 532. 

As described above, computer networks often include Creati°n of QoS Domains ™ d Selection of "feW*™! 

intermediate devices from many differed vendors or, even if Policies 

from the same vendor, having different hardware architec- First, the network administrator preferably identifies vari- 
tures or executing different versions of software. ous regions of his or her computer network 300 to which he 
Accordingly, these intermediate devices provide many dif- 40 or she wishes to have different, high-level traffic manage- 
ferent features and options. For example, a first switch may ment polices applied. The identification of such regions may 
provide only 2 priority queues per port, whereas a second depend on any number of factors, such as geographic 
switch may provide 8 priority queues per port. With regard location, business unit (e.g., engineering, marketing or 
to congestion algorithms and techniques, some intermediate administrative), anticipated network demands, etc. The net- 
devices may only support tail dropping, while others may be 45 work administrator preferably defines a separate Quality of 
selectively configured to provide random early detection Service (QoS) or network domain for each region and 
(RED). Thus, it is extremely difficult for a network admin- assigns a primary policy server (e.g., policy server 322) to 
istrator to configure all of the intermediate devices in eac h QoS domain (e.g., domain 302). Thus, a QoS domain 
accordance with a single, uniform traffic management plan. k basically a logical set of entities and intermediate devices 
As result, network-wide quality of service is generally not 50 denned by the network administrator. As described below, 
available. As described herein, the present invention pro- toe primary policy server is responsible for propagating the 
vides a method and apparatus for allowing network admin- high-level traffic management polices to the intermediate 
istrators to apply high-level traffic management policies that devices within its QoS domain. 

attempt to impose such a uniform plan, despite the presence It should be understood that the policy server 322 may, 

of dissimilar intermediate devices in their networks. The 55 but need not, be physically located within its QoS domain, 

traffic management policies, moreover, may be automati- It should be further understood that back-up or standby 

cally propagated to and implemented by the various inter- policy servers may also be assigned to the QoS domains 

mediate devices. should any primary policy server fail. 

FIG. 4 is a highly schematic, partial block diagram of In addition, the boundaries of the network domains 302, 

policy server 322 in accordance with the preferred embodi- 60 304 may be established so as to only include trusted devices, 

ment of the present invention. The policy server 322 is A "trusted device 1 ' is an entity (e.g., an end station or server) 

comprised of several components, including a policy trans- which is considered to correctly classify the packets that it 

lator 410 having one or more storage devices 412a-412c. sources and to keep its transmission of packets in-profile 

Pob'cy server 322 also includes a policy validation tool (i.e., within the bounds of the traffic specifiers of any 

(PVT) 413 and a policy rule generating engine 414 that are 65 applicable service level agreements). A packet is classified 

each in communication with the policy translator 410, a by loading its user _priority field 114, ToS fields 202 and/or 

device-specific filler entity 416 and a communication engine DS field 220 with a particular value or codepoint. Similarly, 
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an "un-trusted device" is an cod station or server which is 
□ot assumed to correctly classify its own packets and/or 
maintain its flow of traffic within all applicable traffic 
specifiers. Packets from an un-trusted device must be exam* 
ined and reclassified as necessary. Additionally, the flow 
from un-trusted devices must be policed. In a similar 
manner, the ports of an intermediate device that are coupled 
to one or more un-trusted devices are referred to as "un- 
trusted ports", whereas ports coupled to only trusted devices 
arc "trusted ports". 

Once the QoS domains have been defined, the network 
administrator preferably proceeds to select the high-level, 
device-independent traffic management policies that are to 
be implemented within each domain. First, the network 
administrator selects an overall traffic template that estab- 
lishes the different traffic types that are to be supported 
within the respective QoS domain. In particular, the network 
administrator may select one of several available traffic 
templates. An exemplary traffic template may be the traffic 
type list established by the IEEE in the 802. lp standard, 
which defines the following traffic types: best effort, 
background, excellent effort, controlled load, video, voice 
and network control, as described above. Other traffic tem- 
plates include a financial template, a manufacturing template 
and a university or education template. 

FIG. 6 is a highly schematic representation of a financial 
template 610 for use by a network administrator in accor- 
dance with the present invention. As shown, the financial 
template 610 includes a first column 612 listing a plurality 
of available traffic types corresponding to the financial 
template 610. The available traffic types include best effort, 
background, CEO best effort, voice, business applications, 
stock exchange applications, 500 kb/s video conference, 2 
Mb/s video conference and network control. A second 
column 614 identifies a particular differentiated service (DS) 
value corresponding to each traffic type. The DS codepoint 
establishes the overall treatment that is to be assigned to the 
corresponding traffic type within the respective QoS domain 
302. To fit within the first six bits of DS field 220, DS 
codepoints are in the range of 0-63. As described below, the 
DS codepoints may also be used by intermediate devices in 
loading the user_priority and/or TbS fields 114, 202 with 
corresponding values during classification. 

A third column 616 identifies the network users who may 
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614 or may change these values as desired. The traffic types 
and DS codepoints for a given template are preferably 
derived from empirical studies and analysis of the computer 
network operations and usages of such industries and orga- 
nizations. 

In order to select the desired template and enter the 
requested information, the network administrator may inter- 
act with various windows of a graphical user interface 
(GUI). These windows, for example, may present fields, 
such as the entries for columns 616 and 618, having pull- 
down menus that request information from the network 
administrator. The information may be entered by the net- 
work administrator using a mouse or keyboard in a conven- 
tional manner. The user interface, moreover, is preferably 
similar in operation to the Cisco Works Windows interface 
(for configuring router interfaces) or the VlanDirector inter- 
face of the Cisco Works for Switched Internetworks (CWSI) 
interface (for configuring VLANs), both from Cisco 
Systems, Inc. 

It should be understood that other means of associating 
traffic types to users, applications and DS codepoints, 
besides traffic templates, may be employed. It should also be 
understood that network administrators may select different 
traffic templates or adjust their parameters for different times 
of day or for emergency situations. 

Next, the network administrator defines any location- 
specific policies. For example, the network administrator 
may specify that intermediate devices located al the border 
of the QoS domain should only accept traffic that belongs to 
a specific group, such a company employees, department 
members, etc. Any traffic which does not belong to the group 
should be dropped. The network administrator may also 
define one or more lists of global parameters that are to be 
utilized throughout the QoS domain. An example of a global 
parameter list is a prioritized list of queue scheduling 
algorithms from first choice to last choice, such as WFQ, 
WRR and Priority Queuing (PQ). Other examples of global 
parameter lists include congestion algorithms (e.g., RED 
over tail dropping), enabling multi-link Point-to-Point Pro- 
tocol (PPP) fragmentation, if available, and enabling Virtual 
Circuit (VC) merging, if available. 

Associated with the template 610 are one or more data 
structures and, as information is entered into the template 
610, these data structures are preferably updated accord- 
ingly. As described below, these data structures are used to 



take advantage of the various traffic types. For example, the 45 generate the traffic management rules implemented by th 

network administrator may decide that any network user intermediate devices. FIGS. 7A-7E are block diagrams of 

may utilize the best effort, background, voice, 500 kb/s exempl ary data structures associated with template 610. In 

video, 2 Mb/s video and network control traffic types. particular, FIG. 7A is a network user table 710 that maps 

However, only the chief executive officer (CEO) may lake users identified in column 616 of template 610 with actual 

advantage of the CEO best effort traffic type and only 50 user names and/or IP addresses and masks. User table 710 



network users from the marketing, administrative, 
executive, financial analysis and financial planning depart- 
ments may utilize the business applications traffic type. 
Similarly, only network users from the financial analysis, 
financial planning and trading departments may use the 55 
stock exchange applications traffic type. A fourth column 
618 identifies the application programs corresponding to 
each traffic type. For example, available business applica- 
tions may include a spreadsheet application, a word proces- 
sor application, or any of the well-known and commercially 60 
available business applications from SAP AG of Walldorf, 
German or PeopleSoft, Inc. of Pleasanton, Calif. A stock 
exchange application may be TIB from TIB CO Inc. of Palo 
Alto, Calif. The identification of network users in column 
616 and the application programs in column 618 are pref- 65 
erably entered by the network administrator. The network 
administrator may rely on default DS codepoints in column 



preferably includes a user column 712, a name column 714, 
an IP address column 716, an IP mask column 718 and a 
plurality of rows such that the intersection of a column and 
row defines a table entry. As information is entered in 
column 616 of template 610, corresponding entries are made 
in the user column 712 of table 710. As described below, 
information for columns 714, 716 and 718 is subsequently 
added by the policy server 322. FIG. 7B is an application 
table 730 that maps the applications programs entered on the 
financial template 610 to their network protocol, such as the 
Transmission Control Protocol (TCP) or User Datagram 
Protocol (UDP) port numbers. In particular, application 
table 730 preferably includes a first column 732 listing the 
application programs identified in the selected template 610 
and a second column 734 that identifies both the transport 
protocol and the port number for each corresponding appli- 
cation program. 
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FIG. 7C is a classifier tabic 740 that maps DS codepoints, t tTaiKtator-campopent-410 as shown by arrow 420. Policy 

including those specified by the network administrator in the ^translator J41U examines - the . higKrlCTel"poiicics - and corre - 

selected template 610, with corresponding values for use in sponding~data~stractuTes - afld~inay perform" certain-initial J 

classifying or shaping traffic within the corresponding QoS ^proressingrforexai^ 

domain 302, as described herein. In particular, each avail- s^iadividual or group network users by title or department, thO 
able DS codepoint (0-^3), which is loaded in a first column i P°lic£ jra^lor^lOjMy^nUfy-me^acnial users and 
742, is preferably mapped to a DS mark down value ^tam their IP addresses and/or corresponding^ subnet 
contained in a second column 744, a User Priority value ^J^For example, by accessing the repository 326 zad^r 
contained in a third column 746 and a Type of Servicx (ToS) oth f r mformaUon resources, such as DHCP server 329, the 
value contained in a fourth column 748. Preferably, table io Pohcy translator 410 may enter additional xnformaUon in 
740 is reconfigured with a set of default values correspond- * ble 710 : In P !^ CuI "'Al e P° llCy U J^ at0r u 4 T^X? 
ing to the selected template 610. The network administrator me repository 326 or DHCP server 329 to obtain the CEO s 
may, however, access table 740 while establishing the high name > * P IP ma f ™* ^nnaUon may then be 
level policies and modify these values. ^ed in the corresponding entries of user table 710. 
™J,~ -~ ^ , lt Sunilar uiformation, where appropriate, may be obtained for 
FIGS 7D-E are exemplary queue/threshold assignment " such && ^ marketm adminislrative ^ exccuti ve 
tables that map DS codepoints to queues and thresholds de artmentSi from repository 326 or DHCP server 329, and 
depending on the number of queues and thresholds that are entere(J mU) ^ ^ 1W ^ H 41Q 
available at a given interface. For example, FIG. 7D is a first { & conventional database query -response application 
queue/threshold assignment table 760 for an interface sup- such ^ SQL aQd ^ Uh[ we jg nt Directory Access Pro tocol 
porting ^two queues and two thresholds per queue. As shown, 20 to oommunicate ^ ^ it 326 ^ DH CP 
table 760 includes a column 762 764 for each queue and a servef 329 Mtfim!itiw ely, the policy translator 410 may be 
row 766, 768 for each threshold. At the intersection of each onfi d ^ ^ ^^ion. 
column and row is cell 770a-d that contains the set of DS . Z. r , _„ , . ,. . , , 
codepoints for the corresponding queue/threshold combina- ™ c ffif 7 l0 ^ r 732 ° f * c *PPt«tion table 
tion. For example, cell 770a ideVtfiies the set of DS code- 25 730 be cbtained and inserted by the policy trans- 
points (e.g., 0, 4, 8, etc.) to be assigned queue 1 and ^410 In particular, pohcy translator 410 may include a 
threshold 1. Similarly, celi 770d identifies the set of DS d ^ baS ? ^ <*™**cs a PP l ; caUon P~fiJ™ <° transport 
codepoints (e.g., 3, 7, 11, 62, 63, etc.) to be assigned queue P rotoc °l a ° d P° rt ™*«- ^^pplications, such as the 
2 and threshold 2. FIG. 7E is a second queue/threshold ^^n^n^ P ' u ^T^' ^ ^ ' 
assignment table 774 for an interface supporting 2 queues *> ^ TCP/UDP port numbers such^ as, port 80, in accordance 
and 14 thresholds. Accordingly, table 774 includes two col- wth J? ^ "J*" ™* ™ [o ™^™ 
umns 776, 778 (one for each queue) and four rows 780-783 ^ be st °, r ? d by ^ ^n n I « V 
(one for each threshold) whose intersections define a phi- rn^er. Although RFC 1700 provides fixed port numbers 
ralityofc £ lls784 fl -/ I .ThecelU784 a -/ l containlh eS etofDS for hu J dreds ° f applications mere are sull many apphca- 
codepoints for the corresponding queue/threshold combina- 35 *™ ^t do no have predefined, fixed port numbers. The 
t - on r » -i p 0rt num 5 ers utilized by these application are typically 

selected dynamically by the instances of the application 

FIG. 7F illustrates a third queue/threshold assignment program execuung at the sending ^ rece iving devices at 

table 788 for interfaces supporting 5 queues and 2 thresh- the ^ tnc reS p ecU v e communication session is estab- 

olds. Thus, table 788 includes 5 columns 790-794 and 2 \i s hed 

5? "a ^ ^ reecUon u S d f™J Pl^aUty of cells 40 Tq ^ d icall rt nmabcTSf tnc 
798.-;. As ; described above, each cell 798*-, includes a set intcrmcdiale dcviccs m rform a ^1 ^ cction of 
of DS codepoints for the corresponding queue/threshold rcccivcd kcts for iycn communication ^ 
combination. For example cell 798* includes DS code- &mc ^ in clion will revcal thc , numbcrs b 
pomts 0, 10, etc., while cell 798^ mcludes DS codepomts 6, ^ ^ entities. A suitable method for performing 
' ' e c " such stateful inspections is the Context Based Access Con- 
It should be understood that a queue/threshold assignment trol fcaturc of thc i n t crn etwork Operating System (IOS) 
.s preferably generated for each number of queue/threshold from Cisco SystcmSi Inc . For somc application programs, 
combinauons supported by thc interfaces in the network. corresponding software modules may exist for identifying 
It should be further understood that tables 760, 774 and 50 the selected port numbers for any given session of that 
788 may only assign a subset of DS codepoints to queues application program. For example, software module 
and thresholds, rather than all DS codepoints. For example, @h245.voice. inspect is used to identify the port uumbers 
DS codepoints may be segregated into standardized and selected by instances of H323.voice applications. Policy 
private classes or codepoints. Standardized codepoints are translator 410 may be configured with the identity of these 
assigned particular per hop behaviors by the IETF such as S5 modules for insertion in the appropriate entry of application 
expedited or assured forwarding. Private codepoints may be table 710. 

associated with any treatment on an implementation-by It should"bTWa^6od"thirm"csc-data struchircs-(c;g., 

implementation basis. The present invention preferably ublesJ710, 730, 740, 760, 774 and 788) may be stored by j 

maintains the associated behaviors of any standardized po n cy translator 410 at its storage devices 412a-412c. It' 

codepoints. ^ SDOU i d be further understood that the policy generator 410^ 

Generation of Policy Rules Based on the Selected High- may also generate and store additional data structures in c 

Level Policies response to the high-level policies selected by the network - 

Referring to FIG. 4, these high-level policies, including iadministrator. _ " " - - "v____ - r — —J 

the financial template 610 (FIG. 6), data structures 710, 730, ( As^ables* 710, 730, 740, 760/774~and 788 arcToaaed 

740, 760, 774 and 788 (FIGS. 7A-F) and location-specific 6s\ and/or up-dated, the policy rule generating engine' 414 

policies, if any, are then provided to the policy server 322. r accesses this information and creates one or more rules that 

In "particular,^ the" information" is reaivcd~at~ the"7policy \ can be transmitted to the intermediate devices within the j 
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respective QoS doma in-3Q 2. These rules, moreover, whic h 
ma y include one or more access control lists, arc in a forma t 
that is both readable and executable by the intermediate 
devices, as described below. 

First, the policy rule generating engine 414 creates a set 5 
of classification rules. Classification rules are generally 
utilized by intermediate devices to assign a given treatment 
to network traffic based on certai n CTi^CT55^iassource -or 

pragnun^e^ classification 10 
rules, which include one or more objects, are applied at 
specific locations (e.g., an interface or group of interfaces 
coupled to un-trusted devices) or at intermediate devices 
located at the boundary of the QoS domain 302. Location- 

specific classification rules preferably have the following « fo ~ mal of a i^arton-indeVendent behavioral rule is as fol- 
format: l ows 



Next, the policy rule generating engine 414 creates a set 
of behavioral rules, which are utilized to instruct interme- 
diate devices how to treat data traffic assigned a particular 
DS codepoint and/or QoS label by the classification rules. 
Behavioral rules also include one or more objects and arc 
preferably applied at all compliant intermediate devices 
within the QoS domain 302. Behavioral rules may be 
location-specific or location-independent. The preferred for- 
mat of a location-specific behavioral rule is as follows. 

<doca tion> <diie ctio n> <kbe L_1Vst><Be ha vioral_Rulc_Deciiion> 

where the "label__Test" object may be <dsc__Test> (e.g., DS 
codepoint=N, where N is some number, such as "32") or 
<QoS_Label_Test> (e.g., QoS Label=N). The preferred 



<loca tioaxdire ction> <acl><rmo > <Qass Lfica do a_Decisio n_ 
Rule> 

where, the "location" object identifies a particular interface, 
interface type or role as described below, the "direction" 
object refers to whether the rule is to be applied to packets 
at the input, output or both portions of the interface(s), the 
"access control list" (acl) object contains a list of criteria 
statements to be applied to the packets and the "rule man- 
agement object" (rmo) instructs the intermediate device how 
to respond if conflicting actions are returned and the 
"Classification_Decision_Rule" object is the actual rule or 
rules being implemented to packets matching the acl object. 
Although the rmo preferably instructs the intermediate 
device to select the best match, other tie -breaking solutions 
may be presented. The second format of a classification rule, 
which is used with intermediate devices located at the 
boundary of the QoS domain 302, appears as follows. 

<acl><nno > <Qasstfica tion_Decision_Rule > 

Id addition, the acl object may have one of two formats. 

(1) destination IP address or destination IP maskxsource 
IP address or source IP maskxprotocolxsource and/or 
destination port numbers> or 

(2) destination or source MAC address> 

In the preferred embodiment, classification rules are used 
for one of three primary purposes: (1) assigning a DS 
codepoint to packets, (2) assigning a QoS label to packets 
while they are processed withio an intermediate device or 

(3) instructing an intermediate device to shape, mark and/or 
drop oul-of-profiie traffic. For example, a classification rule 
may be used at the border intermediate devices instructing 
them to drop packets with a given source IP address or IP 
mask. A classification rule may also be used to assign a given 
DS codepoint to all traffic associated with a given IP mask 
(e.g., all traffic from the marketing department) or all traffic 
associated with a given port (e.g., port 23 for Telnet). 

As described above, only sixty-four DS codepoints are 
supported by the DS field 220. To extend the concept of 
packet-specific differentiated services beyond sixty-four 
options, the present invention also utilizes Quality of Ser- 
vice (QoS) labels. A QoS label is a name string of any lengtff 
(e.g., an integer, an alphanumeric string, etc.) that may be 
associated with a packet while it remains internal to the 
intermediate device. Classification rules may also be used to 
assign QoS labels to packets based on their source or 
destination address, protocol, application, etc. As described 
below, intermediate devices maintain a mapping of QoS 
labels to traffic types and to the corresponding action to be 
taken or service to be provided. 



<labc l__Test> <B eha vioral_Rule_Detision> 



20 



25 



By applying the label_Test to each packet, the interme- 
diate device determines whether the corresponding 
Behavioral_Rule_Decision should be applied. The 
Behavioral_Rule_Dccision object preferably implements 
one or more of five possible decisions: select queue, select 
queue threshold, set the User.J'riority field 114, set the IPP 
sub -field 210 or shape, mark and/or drop packets satisfying 
the label_Test object. For example, a behavioral rule may 
instruct the intermediate devices to set to "6" both the 
30 User_Priority field 114 and the IPP sub-field 210 of all 
frames or packets whose DS codepoint is "61". Similarly, 
another behavioral rule may instruct intermediate devices to 
place all messages whose DS codepoint is "32" (e.g., data 
frames from a stock exchange application) in a high priority 
35 queue. Behavioral rules may similarly specify a particular 
treatment based on the QoS label, user priority or type of 
service of a packet or frame, such as fast or reliable service. 
In response, an intermediate device may select a particular 
transmission link. Since behavioral rules lack an rmo object, 
40 intermediate devices apply all behavioral rules they support, 
not just the first one. If multiple behavioral rules specify 
contradictory actions, the last one preferably takes prece- 
dence. 

To implement traffic management policies that are inde- 
45 pendent of DS codepoints and/or QoS labels, the policy rule 
generating engine 414 preferably creates <a plurality of) 
configuration rules. In general, configuration rules instruct ^) 
^"interm ediate . . de vices -how^to - set-up their- v arious traffic 
'management components or mechanisms. Configuration ) 
50 ^rules also have a:locationrSpedfic_^n^c<;atioD-irjdependent 
formatwhictrarepreferably-as follows. J) 



C^" _ jdocatioa>*dnftclicin>,<Coiifie^jaqn_J^e 

~ 2<Colifigura Uon^Rule^I^ec isio n > - ~) 
55 — ^^"Ctor^gurali^ 
^to specify 'cejrtai^lobal _ parajM ters~or algorithnr param- 
eters. - For~ex^pte7rtKO^fif^^ 
^object'of a'givenco^figuration rijIe~may contam r a r Iisi"of-^ 
congestiojolgorithms ^ desce nding'order of preference, 
60 such-asr_WFQ,-z.WRRf -PQ and noneTiraddition,' if ' aar> 
^ mtcrrnediateideyice.uses.tail dropand supports four different^ 
^ drop thresholds: per^queue^a^oMguration rulejinayjser the 
r~f6urrthresholds (e:g. T at-50%, 8 0%, Q 3%^fiailOT% of tlje^ 

buffer limit) and assign. a name tQ.eachrthTcshoHrSimilarly,"- - 
65 if .an intclmetiiate device supports WRED,"" a configuration 
rule may be used to set:the;minimum-threshold,. maximum 
threshold and probability constant for each weiglitrAlso;for_~} 
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WRR, a configuration rale may assign the weights to the mines that router 318 has five queues 530c-530c per inter- 
various queues. face 532. Additionally, traffic management controller 512 
The rule generating engine 414 may also combine several may determine thai each queue 530a-530e may support 
related rules into a transaction. More specifically, rules that either RED or tail dropping and supports two settable 
arc meaningful only if applied simultaneously and which 5 thresholds per queue. The traffic management controller 512 
may cause transient miscoofigurations if implemented one at mav further identify the roles assigned to one or more of its 
a time, are combined into a transaction. For example, a interfaces. 

network administrator may want to log as well as drop all R ° lcs P«/crably specify the type or nature of an interface 

attempts to access a subnetwork or LAN by a known hacker. or sub-interface. For example an interface may be trusted or 

Rather than issue a separate rule that only provides for to It may configured to perform policing and shap- 

. , , . i * j - i.-i.-i., mg of traffic from a subscribing network. It may be a 

logging and a subsequent rule for dropping, which might b / cfcbone mlefface ^ ^ { VQlumes of 

result m transitory access by the hacker, these two rules (log ^ tQ ^ backbone network or J bfi b a QoS border 

and drop) are preferably combined into a single transaction. interface. An interface may also have more than one role. 

A transaction start object is preferably used to indicate the ^ parlicular rolc or roles of m mtcr face are preferably 

start of a set of rules forming a transaction and a "transaction 15 assigned by a network administrator utilizing a management 

end" object indicates the end. As described below, the rules protocol, such as Simple Network Management Protocol 

and transactions are accessible by the device-specific filler (SNMP) or CiscoWorks from Cisco Systems, Inc., during 

entity 416 which collects relevant rules for transmission to configuration of the interface. A corresponding flag, label or 

the intermediate devices. name may be maintained by the device to identify the 

To generate the particular rules for a given QoS domain, 20 various roles of its interfaces. For router 318, the interface 

the policy rule generating engine 414 preferably performs a coupled to domain 304 may be assigned the role of policing 

conventional algorithmic transformation on the correspond- and shaping traffic from subscribing domain 304 in accor- 

ing data structures (e.g., tables 710, 730, 740, 760 and 770). dance with one or more traffic specifiers. 

This algorithmic transformation converts the information The assignment of roles facilitates the creation and imple- 

from the data structures into the necessar y access control list 25 mentation of network policies. In particular, global policies 

objects and classification, behavioral and configuration rule may be defined that apply to all interfaces regardless of their 

objects of the corresponding rules. Such algorithmic trans- particular roles. Local policies apply to the role at one 

formations are well -known to those skilled in the art. The specific interface. In other words, policies may be assigned 

objects comprising the various rules, including the rule to roles and roles may be assigned to the various interfaces 

objects themselves, may be defined using Abstract Syntax 30 in the network. Thus, by simply changing the role at a given 

Notation One (ASN.l) which is well-known to those skilled interface, a network administrator ensures that the appro - 

injthe art. priate network policies are automatically propagated to and 

\ TliT^h^jyRanslator'411);also interfaces with -the policy implemented by that interface. Each role, moreover, may 

^validation tool (PVT) 413 to identify any conflicting poli- have a corresponding precedence to resolve any conflicts 

-ties. That is,.me.PVT40.exarm^s.me,higbTleyej policies 35 that might arise al an interface assigned more than one role. 

and-perfoims;a^j^ffi Iifparucukvwe. PVX413 All of this information may be transmitted by the traffic 

determines whether the p olicies as cribe conflicting treaP management controller 512 to the communication engine 

,ments to_t he sa me traffic. For e xam pleTTwo polices may call 510 along with an instruction to send to the information to 
foTciifferent shaping or marking to be applied [to the same) the policy server 322. In response, the communication 
traffic stream. Another policy may be-incomplete by failing) 40 engine 510 preferably formulates a Configuration Request 

-to specifyT^reqnisite'cjandjlionrAll conflictsdetected by the message that includes the information received from the 
PVT 413 are reported to the~pblicy translator 410. The PVTj traffic management controller 512 as a series of objects. The 
413 may also determine, whether Jsufficient-network^ Configuration Request message is then transmitted by the 

resources exist to inclemen t" the policies? Forexample7 a communication engine 510 to the policy server 322. 

policy may require at least one network~path having 3 or 45 At the policy server 322, the Configuration Request 

more queues at each intermediate device along the path. If message is received at the corresponding communication 

no such path exists, the PVT 413 preferably reports this engine 418 and handed to the device-specific filter entity 

condition to the policy translator 410. 416. The device-specific filter entity 416 examines the 

Propagation of the Policy Rules to Intermediate Devices Configuration Request to determine what types of network 

In operation, intermediate devices within a QoS domain 50 resources and services arc available at router 318 and what 

will request traffic management information from the local roles if any are associated with its interfaces. In particular, 

policy server. This information will then be utilized by the the device-specific filter entity 416 determines that router 

intermediate devices in setting their resources and in making 318 supports both RED and tail dropping, has five queues 

traffic management decisions. In the preferred embodiment, with two settable thresholds per queue and an interface 

the policy server and intermediate devices utilize an exten- 55 whose role is to police and shape traffic from a subscribing 

sion to the Common Open Policy Service (COPS) client- network. Based on this determination, the device-specific 

server communication protocol. In particular, the policy filter entity 416 obtains a particular set of transactions and/or 

server and the intermediate devices preferably utili2e the rules from the policy rule generating engine 414 that cor- 

COPS extension described in COPS Usage for Differemi- responds to the network services and resources available at 

ated Services, an Internet Draft Document, dated August so router 318. For example, the device-specific filter entity 416 

1 998, from the Network Working Group of the IETF, which may obtain one or more classification rules instructing router 

is hereby incorporated by reference in its entirety. 318 to classify packets from a given source (e.g., domain 

More specifically, referring to FIGS. 4 and 5, upon 304) with a given DS codepoint and/or QoS label Rules for 

initialization of router 318, the traffic management controller policing and shaping traffic from domain 304 may also be 

512 polls the various components and mechanisms to deter- 65 obtained. 

mine what network resources and services router 318 has to Additionally, the device-specific filter entity 416 may 

offer. For example, traffic management controller 512 deter- obtain one or more behavioral rules that instruct router 318 
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to map packets with various DS code points to specific meter entity 524 so as to monitor the traffic arriving from 

queues and thresholds in accordance with the information domain 304. If out-of -profile traffic is to be marked through 

contained in table 788 (FIG. 7F). More specifically, a first marker entity 526, classification rules may be provided for 

behavioral rule may provide for mapping packets with a DS re-setting the DS codepoints of traffic that is out-of-profile 

codepoint of 0, 10, elc. (e.g., DS codepoints corresponding S based °n the information contained in table 740. 

to cell 798a) to queue 1 (e.g., queue 530a) and the lower Alternatively, if out-of-profile traffic is to be shaped or 

threshold. Another behavioral rule may map packets with a dropped other configuration rules may instruct the associ- 

DS codepoint of 6, 19, 60, etc. (e.g., DS codepoints corre- atcd management controller 512 to set the shaper/ 

spending to cell 79$g) to queue 2 (e.g., queue 5306) and the ^ppcr enuty 528 accordingly 

second threshold and so on. Urns a set of behavioral rules 10 ™* P^cess ^ siimlarly repeated at each of the mterme- 

.... no diate devices within the QoS domain 302 that are compliant 

are obtained 1 that will allow router 318 to map various ^ ^ t mveDlion . Depending on the particular 

packets based on their DS codepoints to queues 530a-530e Qetwork ^ services liable at each intermedi- 

and corresponding thresholds atc devicCf a mcKal xt o{ m fc s will be selected by the 

Filter entity 416 may also obtain one or more configura- device-specific filter entity 416. For example, switch 306 

tion rules. For example, filter entity 416 may obtain a 15 mav similarly send a Configuration Request message to 

configuration rule for use in setting the scheduler 522. In po ]j C y server 322 and receive a Decision Message, 

particular, a configuration rule may provide a list of sched- Furthermore, based on the information contained in the 

uling algorithms in a preferred order (e.g., WFQ, WRR and Configuration Request message from switch 306, including 

Priority Queuing). Another configuration rule may provide the fact that switch 306 is coupled to one or more un-tmsted 

that Virtual Circuit merging should be applied where avail- 20 devices, such as end stations 332-336, the device-specific 

able. Filter entity 416 may access the policy rules via a filter entity 416 may obtain one or more classification rules 

virtual information store, such as the Policy Information for classifying traffic received from these un-trusted devices. 

Base (PIB) specified in the draft COPS Usage for Differen- However, since switch 306 may not operate at the network 

tiated Services document. l a y er * fil ter entity 416 may obtain classification rules for 

Once the device -specific filter entity 416 has obtained a 25 setting the User_Priority field 114 of packets or frames 
set of transactions or rules for router 318, it provides them received on ports coupled to devices 332-336, depending on 
to the communication engine 418 which, in turn, loads them various parameters of the packets or frames, such as port 
into one or more Decision Messages. These Decision Mes- number, protocol type, etc. Filter entity 416 may also obtain 
sages are then transmitted by communication engine 418 to behavioral rules instructing switch 306 how to handle pack- 
router 318. Communication engine 510 at router 318 30 ets based on the user priority value rather than DS codepoint, 
receives the Decision Messages, extracts the rules contained sinoe switcb 306 m *Y Dot be DS-compliant Alternatively, 
therein and provides them to the traffic management con- P ohcv XTWCI 322 ma y P rovide 0Qe or more classification 
troller 512 where they may be decoded by policy rule rules that map User Priority values to DS codepoints so that 
decoder 541. Traffic management controller 512 may also switch 306 ma y a PP lv one or more behavioral rules that are 
build one or more data structures (such as tables) to store the 35 dependent on DS codepoints to packets that have a User 
mappings contained in any received behavioral rules. Priority value. 

It should be understood that intermediate devices learn of 11 should also be understood that less than all of the 

the identity of the policy server 322 through any conven- intermediate devices within a given network may be con- 

tional means, such as manual configuration or a device & ^ t&i to implement the present invention, although in the 

configuration protocol. 40 preferred embodiment, all of the intermediate devices will 

Implementation of the Policy Rules at Specific Interme- be 50 configured, 

diate Devices Th e foregoing description has been directed to specific 

First, traffic management controller 512 proceeds to con- embodiments of this invention. It will be apparent, however, 
figure its components and mechanisms in accordance with that other variations and modifications may be made to the 
the instructions contained in the classification rules. For 45 described embodiments, with the attainment of some or all 
example, to the extent router 318 supports Virtual Circuit of advantages. For example, other client-server corn- 
merging, this feature is enabled. Similarly, to the extent munkations protocols, besides COPS, may be utilized by 
scheduler 522 can implement WRR and Priority Queuing, lhe P olic y and intermediate devices. In addition, the 
traffic management controller 512 configures it to use WRR. present invention may also be utilized with other network 
As packets are received at router 318, they are examined by 50 la y er protocols, such as IPv6, whose addresses are 128 bits 
the packet/frame classifier 516 which reports the contents of lorj g- ^ P resem invention may also be used to classify 
the packet's User_Priority field 114, IPP sub-field 210 other fields of data messages, such as the User Priority field 
and/or DS field 220 to the traffic management controller 512. of the Inter-Switch Unk (ISL) mechanism from Cisco 
Packet/frame classifier 516 may also supply other packet Systems, Inc. Therefore, it is the object of the appended 
header information to the traffic management controller, 55 claims 10 cover M such variations and modifications as 
such as source IP address, port, protocol, etc. In response, 001116 ^thin me S P™ 1 and sco P e of lhe invention, 
the traffic management controller 512 relies on the received ^at k claimed is: 

behavioral rules to determine in which queue 530a-530e the 1 - A method f° r implementing high-level, device- 
corresponding packet should be placed for forwarding and to independent traffic management policies within a computer 
instruct the queue selector/mapping entity 520 accordingly. 60 network having multiple, dissimilar intermediate network 
Similarly, router 318 relies on the behavioral rules to deter- devices, the method comprising the steps of: 
mine which packets to mark down and/or drop. selecting one or more high-level policies; 

Furthermore, to the extent router 318 policies traffic translating the one or more high-level policies into a 

received from subscribing domain 304, additional configu- plurality of executable rules; 

ratioD rules may be provided to router 318 for setting its 65 receiving a request for traffic management policies from 

traffic conditioner entity 518. For example, one or more an intermediate device supporting a set of network 

configuration rules may instruct router 318 to activate its services; 



10/06/2003, EAST Version: 1.04.0000 



6,li 

21 

selecting, in response to the request, one or more rules that 
are compatible with the network services supported by 
the intermediate device; 

forwarding the selected one or more rules to the interme- 
diate device; and 

utilizing the one or more rules to configure ihe set of 
network services at the intermediate device to realize 
the selected high-level policies. 

2. The method of claim 1 wherein the rules formulated by 
the step of translating include at least one of classification, 
behavioral and configuration rules. 

3. The method of claim 2 wherein the step of selecting 
further includes the step of selecting a predefined traffic 
template and loading the selected template with user and 
application information. 

4. The method of claim 3 further comprising the step of 
up-dating one or more data structures associated with the 
selected template as user and application information is 
inserted therein. 

5. The method of claim 4 wherein at least one classifica- 
tion rule includes an access control list object, a rule 
management object and a classification decision rule object. 

6. The method of claim 5 wherein the at least one 
classification rule further includes a location object and a 
direction object. 

7. The method of claim 6 wherein at least one behavioral 
rule includes a label test object and a behavioral rule object. 

8. The method of claim 7 wherein the at least one 
behavioral rule further includes a location object and a 
direction object 

9. The method of claim 8 wherein at least one configu- 
ration rule includes a configuration rule object. 

10. The method of claim 9 wherein the at least one 
configuration rule further includes a location object and a 
direction object. 

11. The method of claim 10 wherein the step of translating 
includes the step of performing an algorithmic transforma- 
tion on the one or more data structures to obtain the 
corresponding classification, behavioral and configuration 
rules. 

12. A policy server for use in implementing high-level, 
device-independent traffic management policies within a 
computer network having multiple, dissimilar intermediate 
network devices and one or more information resources, the 
policy server comprising: 
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means for receiving the high-level traffic management 
policies including one or more corresponding data 
structures; 

a policy translator that is configured to access the one or 
5 more information resources for inserting information in 
the data structures; 

a policy rule generating engine coupled to the policy 
generator and configured to translate the data structures 
into one or more executable traffic management rules; 
10 a device-specific filter entity coupled to the policy rule 
generating engine and configured to select a subset of 
the one or more traffic management rules in response to 
a request from a respective intermediate network 
device having particular traffic management resources 
15 and services; and 

and a communication engine coupled to the device- 
specific filter entity for exchanging requests from inter- 
mediate network devices and selected subsets of the 
one or more traffic management rules. 

13. The policy server of claim 12 wherein the one or more 
20 corresponding data structures include a user table that maps 

individual network users identified in the high-level polices 
to network addresses and maps network groups to network 
masks. 

14. The policy server of claim 13 wherein the one or more 
25 corresponding data structures further include an application 

table that maps application programs identified in the high- 
level policies to network protocol and port number. 

15. The policy server of claim 14 wherein the high-level 
traffic management policies are represented by a selected 

30 traffic template that maps each of a plurality of traffic types 
defined by the selected traffic template with at least one of 
a differentiated service (DS) codepoint, a network user and 
an application program. 

16. The policy server of claim 15 wherein the one or more 
35 corresponding data structures further include a queue assign- 
ment table that maps DS codepoints to queue numbers. 

17. The policy server of claim 16 wherein the one or more 
corresponding data structures further include a queue thresh- 
old table that maps DS codepoints to queue threshold's. 

40 18. The policy server of claim 17 wherein the one or more 
corresponding data structures further include a priority table 
that maps DS codepoints to DS mark down values, user 
priority values and type of service values. 

+ * * * * 
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